A communication network includes various devices that are managed by Management Clients. A common protocol used for inter-communication between a Management Client and a network device is SNMP. An SNMP SET request is used for example by a Management Client to set the parameters of the managed device. A GET request on the other hand is issued by a management client to retrieve the status of the last operation. Multiple Management Clients can interact with the managed device through an SNMP Manager. Such an SNMP Manager can be embedded inside the device or can be an independent entity outside the managed device. Multiple SNMP managers, each of which may be connected to multiple Management Clients can interact with the device via an SNMP Agent.
The typical operation of an SNMP Managed Device is explained with the help of FIG. 1. Four management clients (102, 104, 108, 110) and an SNMP Managed Device 101 that includes a Web Interface 112, a Command Line Interface 114, an embedded SNMP Manager 116 and an SNMP Agent 118 are shown in the figure. Management Client 102 is connected through a Web Interface 112 with the embedded SNMP Manager 116 whereas Management Client 104 is connected to the embedded SNMP Manager 116 though a Command Line Interface 114. Various protocols may be used for communication by the Management Clients to communicate with an SNMP Manager. Management Client 102 in FIG. 1, for example, uses HTTP whereas Management Client 104 uses Telnet for inter-communicating with the embedded SNMP Manager 116. The embedded SNMP Manager 116 in turn is connected to an SNMP Agent 118. Two other Management Clients 108 and 110 are connected to an SNMP Manager 106 that is connected directly to SNMP Agent 118. An SNMP Manager communicates with an SNMP Agent using the SNMP protocol.
Consider for example a user with name John using Management Client 102 with an IP address 10.1.2.1 and connecting to the Web Interface 112 on the SNMP managed device. By using a SET command, the user attempts to configure the low temperature threshold for the device to 60° C. The request fails because the threshold value must be less than the high temperature threshold, which in this example, is currently set at 60° C. There are two problems that are important in this context. The first concerns System Logging 120 in FIG. 1. The log generated by SNMP Agent 118 would only indicate the failed attempt to change the low temperature threshold by user with name ‘John’ (assuming SNMP v3 is used) located at the IP address of the embedded SNMP Manager 116. Note that the IP address of the Management Client 102 that originated the request is lost and only the IP address of the intermediary, the embedded SNMP Manager, which connects Management Client 102 to the SNMP Agent 118 is recorded. The second problem is related to the restricted nature of the error response that is sent back to the user. In this example, a message containing the error-status of COMMIT_FAILED is received by the user. This second problem is caused by the limitations of the error codes supported by SNMP. SNMP requests are defined in RFC 1157 (Internet Engineering Task Force, http://www.ietf.org/rfc/rfc1157.txt). Two entities using the SNMP protocol communicate with each other by using Protocol Data Units (PDU). An important component of the SNMP PDU is a Variable Binding (VarBind) List. Each VarBind in the VarBindList is a two-tuple consisting of an Object ID (OID) and a Value. The OID uniquely addresses a specific parameter and the Value field specifies the value of this parameter.
The response to a SetRequest-PDU is a GetResponse-PDU. From RFC 1157, the GetResponse-PDU contains two fields for error reporting:
error-status of type ErrorStatus
error-index of type ErrorIndex
“Error-index” is an integer value that identifies which VarBind in the VarBindList the “error-status” applies to. The values for “error-status” are shown in Table 1.
TABLE 1Standard SNMP Error CodesSNMP v2cSNMP v3ErrorValueValueNO_ERROR00TOO_BIG_ERROR11NO_SUCH_NAME_ERROR22BAD_VALUE_ERROR33READ_ONLY_ERROR44GEN_ERROR55NO_ACCESS_ERRORn/a6WRONG_TYPE_ERRORn/a7WRONG_LENGTH_ERRORn/a8WRONG_ENCODING_ERRORn/a9WRONG_VALUE_ERRORn/a10NO_CREATION_ERRORn/a11INCONSISTENT_VALUE_ERRORn/a12RESOURCE_UNAVAILABLE_ERRORn/a13COMMIT_FAILED_ERRORn/a14UNDO_FAILED_ERRORn/a15AUTHORIZATION_ERRORn/a16NOT_WRITEABLE_ERRORn/a17INCONSISTENT_NAME_ERRORn/a18As shown in Table 1, the values of “error-status” are limited, and for SET requests that change more than one value only one error can be reported back at a time. One approach to overcome this limitation is for an SNMP Manager to send a GET request to retrieve the status of the last operation. However, this does not work when there are multiple SNMP Managers (as in FIG. 1) communicating with the same SNMP Agent. In this scenario, there is no guarantee that another SNMP Manager will not send a request that changes the status before the first SNMP Manager is able to read it. Thus there is a need in the field for the development of an efficient method and system for identifying the Management Client that originated an SNMP request and for providing a rich textual status and error message that clearly describes the system state or the nature of an error.